A software component for a robot is a reusable and replaceable software module. A user who uses external components configures a robot application using only a combination of components and an interface provided by the components without needing to know the detailed implementation of the interface.
Robot components used in a robot software structure have respective internal states, and operate in an active manner. The robot is controlled by the exchange of data between the components and method calling via a component interface. In order to support this characteristic of the robot, recently, Open RObot Control Software (OROCOS) and a Robot Technology Component (RTC) have presented robot programming methods using components in an active pattern.
In order to run the software components for a robot, components are executed at given periods using the threads of an Operating System (OS). Meanwhile, the number of components used is inevitably large because a robot uses a variety of devices and algorithms. In this case, if a thread is allocated to each of the components, the system resources of the OS are not only wasted, but a thread context exchange process is also performed frequently, thereby deteriorating system performance.
In the prior art, such as OROCOS, components having the same period are made to be processed using a single thread to prevent the deterioration of system performance attributable to the allocation of a thread to each component.
When a plurality of components is processed using a single thread as described above, components registered with a corresponding thread are sequentially processed in each period.
However, if a failure has occurred in a specific component while components registered with a thread were being sequentially processed or if all the components have not been executed within a specific period because the time taken to execute the components was long, the execution of the other components is obstructed. Accordingly, the operation of the entire robot system becomes abnormal due to the failure of the specific component.
In order to solve this problem, in the prior art, a monitor for monitoring the execution of components is added to a system. Furthermore, if the monitor detects abnormality in the execution of a component, a new thread is created and components registered with the new thread are separately executed to prevent a failure in one component from generating an abnormality in the entire system.
However, the prior art in which the monitor is added to the system requires the additional process of sending the execution state of a component to the monitor every time, thereby deteriorating overall system performance.